Integration Guide Universal Robots PolyScope X LS 1.5
This guide describes how to integrate Universal Robots controllers that run PolyScope X with Locator Studio (LS) 1.5. The Robot module is a URScript library (photoneo_locator_X.script, protocol version 1.5.0) that is embedded in a set of .urpx example programs. You do not install a URCap.
Note
For the general concept of the communication, see the Robot communication overview. The supported versions of all Robot modules are listed in the Robot module support matrix.
There is also a URCap variant of this Robot module. It adds a settings page and program nodes to PolyScope X, so you do not write script lines by hand. See Integration Guide Universal Robots PolyScope X LS 1.5 (URCap). Both variants use the same protocol. You can use both in one cell, but not in one program.
1. Prerequisites
The Locator Studio Robot module for PolyScope X is a URScript library, photoneo_locator_X.script, and a set of .urpx example programs. Every example program contains the library. To install the Robot module, you only import an example program. There is no URCap to install and no script file to copy.
Before you start, make sure that your system meets these requirements:
A Universal Robots e-Series robot with PolyScope X system software
PolyScope X version 10.12.1 or higher
A free Ethernet port on the robot controller for the connection to the Photoneo vision controller
The Real-Time Data Exchange (RTDE) interface is enabled on the robot controller (see section 2.2)
A USB flash drive to copy the
.urpxexample programs to the robot controllerA Photoneo vision controller with Locator Studio that supports communication protocol 1.5.0
A Locator Studio solution with at least one calibrated vision system and a configured localization
MotionCam-3D for the dynamic MultiView (Instant Meshing) example. All other examples work with any supported Photoneo 3D sensor.
Note
This guide does not cover PolyScope 5 and CB-Series controllers. For them, use the Photoneo Robot module for PolyScope 5. It uses a different program format (.urp) and keeps the script as a file on the robot controller.
Note
When the library opens the socket to the Action Request Server, it sends the 24-byte brand ID UR/L/1.5.0XXXXXXXXXXXXXX. The vision controller uses this string to select the matching protocol version. Because of this, the vision controller must run a Locator Studio version that supports protocol 1.5.0.
To check the system version on your robot, go to Main Menu → About:
The PolyScope X version is on the first line (Software):
2. Robot Controller Setup
2.1 Network Configuration
First, set the IP address of the robot controller port that connects to the Photoneo vision controller. Go to Main Menu → Settings:
Scroll down to Connection → Network. Select Static as the network method. Enter the IP address and the subnet mask of the robot controller. This guide uses 192.168.1.2 and 255.255.255.0. The network settings are password protected. Press Unlock and enter the administrator password before you change them.
Click Apply Configuration and then Lock and Close to confirm the changes.
Note
The subnet mask 255.255.255.0 is the same as a 24-bit subnet mask. See this table for more combinations: https://dnsmadeeasy.com/support/subnet
Example of a matching network configuration on the vision controller side:
Vision controller IPv4 address: 192.168.1.1 / 24
Robot controller IPv4 address: 192.168.1.2 / 24 (as configured in the previous step)
You can also ping the robot controller from the vision controller. Use the Test connection button on the Network page of the vision controller:
The result of the test (a ping command) is shown in a message: Robot available or Robot unavailable. If the robot is unavailable, check the cables and the network configuration.
2.2 Enabling Real-Time Data Exchange (RTDE)
Locator Studio reads the current joint positions and the tool pose of the robot through the Real-Time Data Exchange (RTDE) interface (port 30004). It uses these values to show the robot in the visualization on the vision controller. You do not install a Robot State Server program on the robot.
Go to Main Menu → Settings → Security → Services and make sure that Real-Time Data Exchange (RTDE) is enabled.
Note
The Services page is password protected. Press Unlock and enter the administrator password before you change an interface.
Note
The calibration request and the hand-eye scan request do not need RTDE. They send the robot pose in the request itself: pho_calib_add_point(tcp_pose) and the optional tcp_pose argument of pho_request_scan. The example programs send get_actual_tool_flange_pose().
2.3 Loading the Robot Module Files
The Robot module consists of the library photoneo_locator_X.script (the request API described in section 3.2 - do not edit it) and these example programs:
pho_main_basic_loc.urpxpho_main_basic_hand_eye_loc.urpxpho_main_basic_multi_vs_loc.urpxpho_main_change_bbox_loc.urpxpho_main_change_solution_loc.urpxpho_main_get_status_loc.urpxpho_get_running_solution_loc.urpxpho_main_reuse_scan_loc.urpxpho_multiview_static_loc.urpxpho_main_loc_MV_dynamic.urpxpho_calibration_auto_loc.urpxpho_calib_loc_hand_eye.urpx
Note
Copy only the .urpx programs to the robot controller. Every example program already contains the library as a Script node in its Before Start sequence. PolyScope X keeps the script inside the program, not in a separate file on the robot controller. The separate photoneo_locator_X.script file is for reference and for the update procedure in section 5.
Copy the .urpx files to a USB flash drive. Connect the drive to the USB port of the teach pendant or of the robot controller. Then click Main Menu → System Manager:
In the System Manager, you open, save and change all programs on the robot. Press + Program, then Import Program, and select the example programs on the USB flash drive:
After the import, the Locator Studio example programs are on the Programs page of the System Manager. You can open them from there:
Note
PolyScope X does not keep robot programs as files in a /programs directory (as PolyScope 5 does). It keeps them in an internal application store. Because of this, you cannot copy programs with scp or an FTP client. Import them from a USB flash drive in the System Manager, as described above.
SSH access to the robot controller is available for diagnostics. It is disabled by default. To enable it, go to Main Menu → Settings → Security → Secure shell. There you set the port, the authentication method (password, key or both) and the authorized keys.
2.4 Tool (TCP) Setup
Locator Studio sends object poses in the robot base coordinate system. During the calibration and during a hand-eye scan, it must know where the robot flange is. The tool pose that the robot reports depends on the active end effector. Locator Studio works best with an all-zero tool, because it compensates the tool offset on the vision side. Use a zero tool for the calibration too.
On the left side, go to Application → End Effectors:
Make sure that the Tool_flange end effector has zero position and zero orientation values:
Note
The example programs send get_actual_tool_flange_pose() with the calibration request and the hand-eye scan request. This pose does not depend on the active end effector. These requests are correct also when a non-zero tool is active.
Note
The picking motions are different. The example programs move the robot to the pose from Locator Studio with the TCP that is active at that moment. For picking, the active end effector must describe the real gripper. If you need both, activate your own end effector for your own movej / movel motions, and switch back to Tool_flange for the Photoneo requests.
3. Robot Module
Note
We strongly recommend that you read the Photoneo robotic API before this section.
3.1 Connection to the Photoneo Vision Controller
The program opens the connection to the Action Request Server on the vision controller at the start with pho_wait_for_server. You can send requests only after the connection is open. The function is defined in photoneo_locator_X.script. Do not edit it.
Request |
Script definition |
Input |
Populates |
|---|---|---|---|
Connect to the Action Request Server (vision controller) |
|
|
|
The example programs call pho_wait_for_server(IP_ADDRESS) in Before Start, with IP_ADDRESS set to "192.168.1.1". Change this value to the IP address of your vision controller. The function closes the old socket before it opens a new one, so every program start opens a new connection.
Note
If the socket cannot be opened, the library sets PHO_ERR_CODE to 3 (communication failure) and stops the program. When the connection is open, the Deployment page of Locator Studio shows the Action Request Client as CONNECTED (green).
3.2 Request List
This section describes the API functions of the Robot module. Use them for high-level control of the Locator Studio application. For details about each request, see Action requests.
Note
These functions are defined in the API section of photoneo_locator_X.script. Do not edit them.
Note
The ID column shows the request ID that is sent over the Photoneo communication protocol. Where two script definitions are shown, the second one is a short alias that calls the first one.
Request |
ID |
Script definition |
Input |
Populates |
|---|---|---|---|---|
19 |
|
Vision system ID Flange pose (optional, hand-eye): |
Non-blocking. Collect the response with |
|
Wait for scan |
- |
|
Timeout [s] (optional, -1 = wait without limit) |
|
30 |
|
Vision system ID Flange pose (optional) |
Non-blocking. Collect the response with |
|
31 |
|
Vision system ID Flange pose (optional) |
Non-blocking. Collect the response with |
|
20 |
|
Vision system ID Number of requested objects (0 = all) |
|
|
Get all objects |
20 |
|
Vision system ID |
As Get objects, with the number of objects set to 0 |
Get single object |
20 |
|
Vision system ID |
As Get objects. Also copies the first pose to |
22 |
|
Vision system ID |
|
|
33 |
|
Vision system ID Bounding box ID |
|
|
25 |
|
Solution ID Vision system ID |
|
|
5 |
|
Flange pose: |
|
|
27 |
|
None |
|
|
26 |
|
None |
|
|
9 |
|
Solution ID |
|
|
10 |
|
Solution ID |
|
|
11 |
|
None |
|
|
12 |
|
None |
|
|
100 |
|
None |
|
Three requests are non-blocking: pho_request_scan, pho_trigger_scan and pho_reuse_scan. Collect the response with pho_wait_for_scan_completion(). With a hand-eye sensor, keep the robot still until the scan response arrives. With an extrinsic sensor, the robot can move in the meantime if it stays out of the scanned scene. The only exception is dynamic MultiView, where the sensor scans while the robot moves. If a response is still pending, every other request collects it before it sends its own request, so no response is lost. All other requests wait until the vision controller answers.
Note
If you call pho_wait_for_scan_completion() when no scan request is pending, it shows a Program flow error message and halts the program.
3.3 Object Picking and the Approach Pose
A complete Locator Studio cycle has four steps:
pho_wait_for_server- once, at the start of the program.pho_request_scan- start the scan and the localization.pho_wait_for_scan_completion- wait until the vision controller confirms the scan.pho_request_get_objects- read the poses of the localized objects frompho_object_poses.
Locator Studio sends the pose of the object itself. Unlike Bin Picking Studio, it does not plan a trajectory. The robot program controls all motion: it calculates an approach pose above the object, moves there, moves to the object, closes the gripper and moves away. The library has two helper functions for this:
Function |
Input |
Returns |
|---|---|---|
|
|
The target pose with |
|
|
The offset pose. The function first checks that this pose and the poses near it are reachable. |
Note
Use pho_get_approach() for a vertical offset. Use pho_get_offset() when the offset must follow the orientation of the object. The Tool methods offset along the axis of the object, so the robot approaches a tilted object along its own direction. pho_get_offset() also checks the object pose, the offset pose and two safety poses (2 cm past the object and 2 cm past the offset pose) with is_within_safety_limits(). If a pose is not reachable, it shows a blocking message before the robot moves. pho_get_approach() does not check anything. Section 4.1 describes the offset methods.
3.4 Result Variables
The requests do not return values. They write their results to global variables of the library. The robot program can read these variables at any time after the request. A variable keeps its value until the next request changes it. For the meaning and the units of the values sent by the vision controller, see Info data.
Variable |
Set by |
Meaning |
|---|---|---|
|
every request |
Response code of the last request (see section 3.5) |
|
every request |
|
|
|
List of up to 100 object poses in the robot base coordinate system ( |
|
|
Number of object poses that were received |
|
|
Copy of the first received pose |
|
|
Width and depth of each object [mm] - only for localization without a CAD model |
|
|
Rotation of each object around Z [deg] - only for localization without a CAD model |
|
|
Class label from an AI solution |
|
|
Maximum Z height [mm] and tilt angle [deg], used by layer solutions |
|
|
Number of localized objects |
|
|
Number of objects that are ready to be picked |
|
|
0 = processing has finished, 1 = localization is still running |
|
|
Calibration accuracy sent by the vision controller [µm] |
|
|
Camera pose that results from the calibration |
|
|
ID of the solution that is deployed on the vision controller |
Note
The library converts pho_dimensions_rot and pho_angle from milliradians (as sent) to degrees. All other values are stored as they are sent.
3.5 Response Codes
Every request writes its result to PHO_ERR_CODE. If the code is not 0, the request also sets PHO_OCCURRED_ERR. The library defines a named constant for each code. Your program can compare the code with the name instead of the number, for example if PHO_ERR_CODE == PHO_NO_OBJ_RUN:. Codes 3 and 4 stop the program. All other codes are only reported, and the program continues, so that it can react. For the full description of each code, see Error codes.
Code |
Constant |
Meaning |
|---|---|---|
0 |
|
The request was successful |
1 |
|
Service error - the process that handles the request is not available (for example, no LS solution is deployed) |
2 |
|
The vision controller does not know the request |
3 |
|
Communication failure - the program stops |
4 |
|
Incorrect data received - the program stops |
5 |
|
The response did not arrive within the timeout |
450 - 459 |
|
Solution management: invalid solution ID, another solution is running, start or stop error, solution incomplete, invalid brand ID, solution already running, operation forbidden |
460 - 469 |
|
Calibration: invalid vision system, calibration already running or not running, stop or start error, calibration disabled, not enough calibration points, calibration accuracy above the allowed threshold, scanner not available, calibration forbidden |
500 |
|
The requested vision system does not exist |
501 |
|
Empty scene |
502 |
|
No object found yet, the localization is still running |
503 |
|
No object found, the localization has finished |
504 |
|
All objects found so far were rejected, the localization is still running |
505 |
|
All objects were rejected, the localization has finished |
3.6 Example Programs
The Robot module includes several .urpx example programs. They show how to use the requests from section 3.2 for different use cases. All main examples have the same structure: the Before Start sequence connects to the vision controller and sets the offset parameters. The Photoneo pick and place loop folder contains the Picking and Placing folders.
Example program |
Description |
|---|---|
|
The basic template - start here. It shows the complete workflow: connect to the vision controller, send a scan request, wait for the scan, read the object poses with
Every request writes its result to |
|
The same as |
|
The same as |
|
The same as |
|
The same as |
|
The same as |
|
The same as |
|
Shows the reuse scan request. Use it when the scene has not changed since the last scan, but the localization must run again with a different configuration (another object, another bounding box or other settings). When |
|
Static MultiView (meshing) example. The program combines several scans before the localization starts. This helps with complex scenes or large objects. The robot stops at each scanning position (Start, Middle, End), calls Scan limit: for best performance, use fewer than 10 scans in total. |
|
Dynamic MultiView example: Photoneo Instant Meshing with MotionCam-3D. A parallel thread calls Requirements: MotionCam-3D is required. Standard PhoXi 3D Scanners do not support dynamic scanning. Trajectory: keep the scanning trajectory smooth, avoid sudden rotations and keep the scanned area in the field of view, so that the tracking is not lost. Scan limit: use no more than 60 scans in total. |
|
Automatic calibration of a statically mounted scanner. In Before Start, the program stops the running solution and calls Requirements:
Calibration accuracy: as a general rule, the calibration error must be less than 3 mm. A larger error usually shows a systematic problem in the calibration setup. Important: the scanner is statically mounted, so the calibration object is the calibration ball mounted on the flange or gripper. The ball moves with the robot through the calibration poses. It must stay in the same place on the flange or gripper as in the initial calibration - do not remount or move it in between. |
|
Calibration of a hand-eye scanner (mounted on the robot flange). The nine calibration poses are taught with the scanner on the flange. The program contains only the nine |
4. Runtime
When the solution is completely configured on the vision controller, do the last steps on the robot side and run the Locator Studio program.
4.1 Approach and Deapproach Offset Parameters
Locator Studio sends the pose of the object. The robot must not move straight to it. The example programs approach the object from a distance and move away in the same way. The folders Approach offset parameters and Deaproach offset parameters in the Before Start sequence contain the values for this:
Variable |
Delivered value |
Meaning |
|---|---|---|
|
0.1 |
Approach distance in meters |
|
|
Axis for the approach offset |
|
|
Method used to calculate the approach offset |
|
0.2 |
Deapproach distance in meters |
|
|
Axis for the deapproach offset |
|
|
Method used to calculate the deapproach offset |
The library accepts these methods:
Base Offset - adds the offset along the selected axis in the base coordinate system
Base Plane - sets the coordinate along the selected axis to the offset value (base coordinate system)
Tool Offset - moves the pose back by the offset along the selected axis of the object (tool) coordinate system
Tool Plane - calculates where the Z axis of the object crosses the plane at the offset value along the selected base axis
Note
pho_get_offset() uses these four methods and checks that the calculated poses are reachable before the robot moves. The simpler pho_get_approach(target, offset_z) ignores the method and axis variables. It always adds the offset to the Z coordinate in the base coordinate system and does not check reachability. See section 3.3.
4.2 Teach Positions
Open pho_main_basic_loc or another template. Before you run the program, touch up these five poses to fit your cell: Scanning, Pick_start, Before_place, Place and Deappr_place. The robot scans from the Scanning pose. It returns to Pick_start before it approaches the next object.
The MultiView examples use the scanning poses Start, Middle and End instead of Scanning. The calibration examples use Calib_Home and the nine poses Calib_Pose_1 to Calib_Pose_9.
Note
Do not rename these waypoints. The program uses their names. If you rename a waypoint, the move nodes have no target.
4.3 Runtime Prerequisites
Before you run the Locator Studio program from the robot side for the first time, make sure that:
the Locator Studio solution is correctly configured on the vision controller
the network setup on the robot side is complete
RTDE is enabled (section 2.2)
IP_ADDRESSin Before Start is the IP address of your vision controller (section 3.1)all vision systems in the solution are calibrated
all poses in the main program are touched up correctly
the approach and deapproach offsets are set for your gripper (section 4.1)
the gripper commands are ready and work
4.4 Running the pho_main_basic_loc Program
Deploy your solution. Until the robot program connects, the Deployment page shows the Action Request Client as DISCONNECTED:
Note
We strongly recommend that you set the Speed slider on the teach pendant to 20% before you run the program for the first time.
Start the program. When the connection is open, the Action Request Client status changes to CONNECTED. The sensor takes the first scan and the localization starts.
If there is a pickable object in the scene and the robot controller receives its pose, the robot starts to move to the first object.
If everything looks correct, continue to move the robot to the first object and check the path. If the robot stops too far from the object or pushes the object too deep, adjust the object origin or the tool setup.
If the robot movement is correct, set up your own placing routine and slowly increase the speed to 100%.
The Photoneo Universal Robots interface now works. To improve your application, use the example programs in section 3.6 and the request list in section 3.2.
5. Robot Module Update
To update the Robot module to a version that matches your Locator Studio version, do these steps:
Import the new example program. Import the
.urpxprogram of the new Robot module version as described in section 2.3. It already contains the matchingphotoneo_locator_X.script, so you do not replace a script file on the robot controller.Or replace the library in your own program. Open your program and select the Script node with the Photoneo library in the Before Start sequence. Press Edit Script and replace its content with the content of the new
photoneo_locator_X.script.Check the API changes. Read the API changes of the new Robot module version and update the request calls in your program if necessary. The changes from LS 1.4 are listed in section 7.
The library version is written in the header of the library (Zebra Technologies Locator communication library v 1.5.0). The brand ID that the Robot module sends to the vision controller is described in section 1: UR/L/1.5.0 for the 1.5 library.
6. Version and Brand ID
Item |
Value |
|---|---|
Robot module version |
1.5.0 ( |
Locator Studio |
1.5 |
Brand ID (sent by |
|
Action Request Server port |
11003 |
Robot state (RTDE) |
Port 30004 on the robot controller - read by the vision controller, no robot program needed |
7. Migration
For the changes in the communication interface, see Migration from LS 1.4.x to LS 1.5.x.
Two scan functions have new names in the 1.5 library. The delivered example programs already use the new names. If your own program was written for the 1.4 library, rename these calls when you replace the library (section 5), and add the wait shown in the table. Otherwise the program stops with an error about an unknown name.
Up to 1.4 |
From 1.5 ( |
Note |
|---|---|---|
|
|
New name, same behavior |
|
|
New name. It also accepts an optional pose, like the other scan requests. Unlike |